4. THE APP MODEL

The new app model enables you to build applications that act like they are part of SharePoint, but they are not. As mentioned previously, apps run 100 percent outside of the SharePoint server within the context of the client browser (via client-side scripts, REST, and CSOM) or in remote servers hosted in the cloud or your own infrastructure.

SharePoint-Hosted Apps

SharePoint-hosted apps are available in all deployment scenarios. These types of apps are deployed to SharePoint, and their business logic executes within the client browser. These types of apps cannot interact with other apps because they run in isolation.

Provider-Hosted Apps

Provider-hosted apps are available in all deployment scenarios. These types of apps are deployed to SharePoint, and the bulk of their business logic executes as server-side code external to SharePoint, such as on another web server in the corporate network or in the cloud.

A provider-hosted app (also sometimes referred to as a developer-hosted app or self-hosted app) cannot interact with other apps.

Azure Auto-Hosted Apps

Azure auto-hosted apps are available only in the Office 365 deployment scenario. These types of apps are similar to the provider-hosted apps except the external components, which consist of a Windows Azure website and optionally an Azure SQL database, are invisibly provisioned by Office 365. An Azure auto-hosted app cannot interact with other apps. Figure 4 shows an end-to-end platform support and tooling experience (Visual Studio, SharePoint Designer, Access, or Napa) across Office 365 and Windows Azure to enable an Azure auto-hosted app model.

FIGURE 4

As a developer or Office 365 customer, you do not need to set up anything to integrate Windows Azure with Office 365. You don’t even need to have a Windows Azure account. The integration is already there and provided automatically when you sign up for tenancy in Office 365. When an end user decides to install an Azure auto-hosted app, Office 365 automatically deploys and provisions a copy of the app as a Windows Azure website, and Office 365 can then manage it on behalf of the end user who installed it. This new type of app provides a compelling way to create and distribute your apps in an auto-provisioning way.

Apps or Solutions — Which Way to Go?

The answer to this simple question can become surprisingly difficult. When developers start coding a solution, they have no idea how big the solution may grow over time. There are several factors that impact the way solutions evolve, such as requirement changes, timeline pressures, and budget cuts. To overcome this up-front uncertainty, you always must make assumptions and build and deliver your solutions based off those assumptions. Remember, shipping is a feature. After your product is shipped, you can always monitor the usage pattern and user adoption, and come back and iteratively improve your solutions. To make assumptions you need to ask yourself questions and compare the answers to find your preferred options.

Apps provide the highest level of isolation in three levels: process, users, and content levels. Apps also provide the most flexibility for standard web technologies and infrastructure choices because they will not run on the same machines that SharePoint 2013 is installed on.

When deciding between SharePoint apps and SharePoint solutions, there are several factors that can help you decide whether you should develop an app or a solution:

• Server-side object model — A server-side object model is not allowed in apps. Use the restricted server-side code of sandboxed solutions or the unrestricted server-side code of farm solutions.
• Access to external resources — Apps can be granted permission, when installed, to content outside the hosting SharePoint website scope (SPWeb); for example, the entire site collection. It’s obvious that all types of apps can access web services and other sources that are not hosted in SharePoint if they have access to them.
• Target user — This one is easy; for example, if you build an extension that allows farm administrators or web application administrators to do some maintenance or cleanup work, it’s probably not a good idea to do it in an app. Farm solutions would not be a good candidate for a SharePoint app.
• Complexity — There are still tasks you can do using either apps or solutions, and the level of complexity is the same or a bit more complex if you do the tasks in apps. For example, you can deploy custom field controls, site columns, content types, or branding artifacts using apps or sandboxed solutions. It’s probably more difficult to do these tasks in apps. If you ever get stuck in such scenarios, lean toward apps because you know they are the future that SharePoint and many other products are moving toward.
• Dependency — If you build a custom extension tightly coupled with another custom extension and it requires the dependent extension to be present prior to the installation, building it as an app is probably not a good idea. Again, apps are isolated and self-contained containers that should easily install, upgrade, and uninstall. Similarly, you should not use an app to install resources that other apps or solutions depend on because this would either block the clean uninstallation of the app or break the other extension when the app is uninstalled.
• Scope — SharePoint-hosted apps should not be full applications, such as case management or payroll. A SharePoint-hosted app should do only a few closely related tasks that surround only a few primary resources. Unlike previous versions where you used to build mega business solutions to target various use cases, your SharePoint-hosted apps are isolated, transactional in nature, and built to satisfy specific business needs. If you need full applications, either use SharePoint solutions or use cloud-hosted apps.

Table 1 summarizes the decision factors that you should consider when deciding between SharePoint solutions (farm or sandboxed) and apps.

TABLE 1: SharePoint Solutions and Apps Head-to-Head

Table 2 summarizes the decision factors that you should consider when deciding between types of apps.

TABLE 2: Apps for SharePoint

If you put together everything you’ve learned so far, it should look like Figure 5. Packaging options in hosted or hybrid deployments depend on the hosting provider or how SharePoint is deployed and therefore are not included in Figure 5.

FIGURE 5

The App Security Model

Unless you have turned on anonymous access for a SharePoint site, every incoming request that lands in SharePoint must identify itself, which is the process known as authentication. The authentication is essential because if SharePoint doesn’t know who you are, it doesn’t know to authorize your access level to its resources.

Due to the changes in its programming model, the SharePoint 2013 authorization pipeline must deal with two different types of identities: user identity and app identity. The latter is new in SharePoint 2013.

To understand the need for app identity in SharePoint 2013, here’s an example: Think about a scenario in which you want a remote app to access some product pictures in your site and tweet them to a Twitter feed owned by the Marketing Department. Obviously, the Twitter app needs to log in to SharePoint first before it can access and tweet those pictures. One way to do this is to give the app a set of credentials (username and password) so that it can sign in as you or someone else and complete its work. This is not a good option for a number of obvious reasons. First, everything in SharePoint is tied to a user identity, and the SharePoint authorization pipeline must distinguish the Twitter app and its actions from you and your actions — that’s just how SharePoint works. Second, the Twitter app can do anything you can do such as deleting content or posting a comment to the CEO’s blog on behalf of you. You don’t want that either. Furthermore, what if you decided not to use the Twitter app anymore? What happens to your credentials? What if you use many apps like the Twitter app? How do you manage the credentials for many apps?

SharePoint tracks user identities using SharePoint security groups and Access Control List (ACL) entries stored in the content databases. For authenticating and authorizing app identities, however, SharePoint takes a different route.

First, consider authentication. An app is a first-class principal in SharePoint 2013; therefore, it needs its own identity. App identity is provided to SharePoint by Azure Access Control Service (ACS) via a widely adopted Internet security protocol called OAuth. OAuth 2.0 is the next release of OAuth that requires HTTPS.

The new architecture enables SharePoint 2013 users to approve an app to act on their behalf without sharing their credentials. To enable this, a number of different types of security tokens are issued, and there are back-and-forth communications between user, SharePoint, ACS, and the app itself, all done to ensure an app can transparently authenticate to SharePoint.

When SharePoint 2013 receives an incoming request, the process starts with examining the request to see if it contains a sign-in token representing a user identity. If the user identity is found, SharePoint assumes that the request was initiated by an authenticated user and not an app. SharePoint then inspects the target URL of the incoming request to see whether it references a standard SharePoint site or a subsite associated with an app. (It’s called AppWeb.) If the incoming request targets a standard site, SharePoint 2013 follows its typical authorization process identically to how things worked in SharePoint 2010. If the incoming request targets an AppWeb, however, SharePoint 2013 initializes the context with both a user identity and an app identity.

When an incoming request does not contain a sign-in token, SharePoint 2013 knows that it was not a user who initiated the request. In this scenario, SharePoint looks for an OAuth token to identify the remote app (provider-hosted). When SharePoint 2013 finds this security token, it sets up the context with the app identity and optionally the user identity.

Now, consider authorization.

After a provider-hosted app authenticates to SharePoint and the right context is created, SharePoint determines what actions the app is authorized to perform in the calling context. It’s worth mentioning that SharePoint 2013 does not leverage ACS or OAuth protocol in any way to track or pass app permissions. Instead, SharePoint relies on its own internal content databases to track authorization just as it does with user permissions.

Each app has a manifest.xml file where the developer can define a list of resources that the app needs access to using the AppPermissionRequests element. The following code snippet shows an example of this element used in a provider-hosted app:

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" 
  Right="Read"/>
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list" 
  Right="Write">
    <Property Name="BaseTemplateId" Value="101"/>
  </AppPermissionRequest>
  <AppPermissionRequest Scope="http://sharepoint/userprofilestore/feed" 
  Right="Post"/>
  <AppPermissionRequest Scope="http://exchange/calendars" Right="Schedule"/>
 
</AppPermissionRequests>

Note the highlighted line in the code snippet. The app permission requests enable the app-only policy, which means that only the app, and not the current user, requires the needed permissions. If an app-only policy is not used, both the app and the current user require the necessary permissions to complete a task such as accessing the entire site collection or writing to a list. The result would be a context that contains both the app and the user identities.

An important aspect of an app-only policy is that it can elevate the permissions of the app so that it can do more than the current user. It also makes it possible for an app to call back to SharePoint and access the app web (the SharePoint website associated with the app) and parent web (for example, a SharePoint website that is hosting the app) when there is no current user. When an app with AppPermissionRequest entries is installed by a user, the user must grant permissions to those placed in the manifest.xml file and requested by the app at the time of installation.

As mentioned previously, when creating a provider-hosted app that needs to communicate back to SharePoint, there are several types of security tokens needed for back-and-forth communications such as a context token and an OAuth token. Thankfully, Visual Studio automatically adds a helper class named TokenHelper.cs to help you access and work with the security tokens.

ACS cannot be used in on-premise deployments without involving an Office 365 tenancy. That means there is no OAuth token either. Apps need to use a different security token created using the Server-to-Server (S2S) configuration. 

Just because apps run in their own domain (to prevent cross-site scripting attacks) and they are written using JavaScript, it doesn’t mean they are secure. As a developer, you are still on the hook to think about the security breaches and sensitive information disclosure caused by how you have designed your apps. Here are some examples of SharePoint security considerations:

• SharePoint-hosted apps are not authorized at a specific list or web level. In other words, if a SharePoint-hosted app is authorized to write to one list, it can also write to another list.
• When a user grants permission to a provider-hosted app. Granting permission is a one-time only process, so if the app’s logic and its code behind change later, SharePoint won’t detect this.
• When the app uses its OAuth token to perform some tasks, another app on the same page can use this token to perform actions on behalf of the app identity, the user identity, or both. It’s also possible for a hacker to hijack the OAuth token in an unsecure communication channel (HTTP).

As you can see, there are many security considerations in app development you need to be aware of. To make apps secure and to protect sensitive information, you need to design with security in mind and to use HTTPS to secure the communication channel.